\section{Interface Design}
%\textbf{SOMEWHERE WRITE ABOUT KLIPPER KLISTER TEST - Gustav, 27 May}

In this section the initial design of the program will be covered along with the reasons for why the different choices were made.

\subsection{General Look of the Program}
The general design of buttons, sliders, etc. were predetermined before the design of the program was started. This is due to the fact that the program will utilize the GUI (Graphical User Interface) library called ControlP5 \cite{websiteControlP5}, which already has all the GUI elements that are needed. It was deemed necessary to save time in both designing the program as well as later on when the design had to be implemented. The standard design of the ControlP5 GUI is made in varying shades of blue and gray as seen in figure \ref{fig:controlP5}, so this became the default color palette. ControlP5 was also chosen because its default appearance was in line with what was intended as a general feel for the program.

\begin{figure}[htbp]
\centering
\includegraphics[width=0.7\textwidth]{images/TheoryDesign/controlP5.jpg}
\caption{The standard design of ControlP5 \cite{controlP5}.}
\label{fig:controlP5}
\end{figure}

As ControlP5 was chosen to build the GUI on, the ControlP5 design was the foundation for the interface. It was chosen to go with these dark colors from ControlP5, because it is easier on the eyes while also being aesthetically pleasing to look at; something that is important when having to look at it for longer periods of time. Furthermore, this simple combination of colors complimented the choice of a minimalistic design. This will be looked further into in the testing chapter \ref{testChapter}.

\subsection{Structure of the Program}
The application was designed following the requirements so far. These will be referred back to with the identity tag (\textbf{R\#}):

\begin{enumerate}
\item \textbf{Functional requirements:}
\begin{enumerate}
\item The product needs to visualize audio concepts.
\item The product needs to play back audio.
\item The product needs to implement certain effects based on the sound course of fourth semester of Medialogy.
\item The product needs to show in real-time how tweaking parameters changes the result of the output signal.
\end{enumerate}
\item \textbf{Non-functional requirements:}
\begin{enumerate}
\item The product must not require understanding of sound theory prior to use.
\item The product needs to work as a supplement to a sound course.
\item The product needs to be easily accessible to students.
\item The design of the program should fit on both PC and tablet.
\end{enumerate}
\item \textbf{Usability and user experience requirements:}
\begin{enumerate}
\item The interface needs to be simple to not intimidate the student inexperienced in sound theory.
\item The interface needs to be quick to navigate for the student to easily use it during courses with as little distraction as possible.
\item The interface must be simple and easy to navigate with as few button presses and menus as possible.
\item The interface needs to minimize possible errors made by the user, to motivate the user to freely play around with the controls.
\end{enumerate}
\end{enumerate}

The focus of the program is not to add effects to sound files for the purpose of giving the user an editorial tool, but for the purpose of helping the user understand the results of audio effects - even though it can, to some degree, be used as an editorial tool. Because of this, it is important that the user doesn't have to spend a lot of time learning the ins and outs of the program but can pick it up and get started learning about audio effects straight away (\textbf{R2c}). For this reason, all controls need to be laid out in plain view as much as possible so that the user does not have to spend time looking around trying to find controls in obscure places, something that easily becomes the case when dealing with more advanced programs (\textbf{R3a}, \textbf{R3b}). Another important aspect is that the program should reserve as much space as possible for the visualization of the sound and the control of the input signal as this is the main focus of the program (\textbf{R1a}, \textbf{R1b}). The design should be minimalistic and encourage the user to play with as many controls as possible (\textbf{R3a}). Every tweak of a control should be instantly visible and/or audible, as to enhance understanding (\textbf{R1d}). The program's initial design draft can be seen in figure \ref{fig:finaldesign} and further down as the design of the different parts of the program are explained.

\begin{figure}[htbp]
\centering
\includegraphics[width=0.7\textwidth]{images/TheoryDesign/finaldesign}
\caption{The final design draft of the program running on a tablet.}
\label{fig:finaldesign}
\end{figure}

\subsubsection{Effects \& Filters}
The \textit{Effects \& Filters} tab is shown in the upper right corner at all times. This is where most of the controls are found. Tapping it brings up the Effects \& Filters list. This is shown on the left in figure \ref{fig:barmodes}. By tapping an effect, or dragging it to the \textit{Active Effects} list on the right, the corresponding workspace for that effect replaces the Effects \& Filters list, as shown on the left in figure \ref{fig:barmodes}. The two windows are visually distinguishable.

As the order in which the effects are added is important, the list called Active Effects is shown on the right at all times. By dragging and dropping the effects in it, the user can rearrange them. By tapping one of them, the workspace associated with that specific effect shows up. In the bottom of the workspace of each effect is a remove-button to remove the effect from the list and thereby ending its effect on the input signal. Each effect is represented by a small icon to save space and give the user a quick overview.

The tab-based design was needed, because representing every effect in the window simultaneously would be impossible due to lack of space. The drop-down menu was incorporated to save space while only adding one button press and one menu (\textbf{R3c}). This also made it possible for the user to more easily control the order of the effects. For the Active Effects list, it was originally planned to implement a pop-up menu in the bottom, like the Effects \& Filters drop-down. But it strongly went against requirement (\textbf{R3c}) as adding an effect to the list would require a series of button presses and an additional menu. It was decided to implement a small list to the right with each effect represented by icons. Adding an effect now only needed one menu and two button presses instead of several more. Removing an effect proved to be a bigger problem nevertheless. On a computer it could have easily been solved with a small cross in the corner of each icon, but abiding requirement (\textbf{R2d}) it was concluded that this was not possible on a tablet, as button presses here are not as precise as with a mouse. The best solution was to add a remove-button at the bottom of each effect in its corresponding workspace. This unfortunately added an additional button-press per effect the user wanted removed.

\begin{figure}[htbp]
\centering
\includegraphics[width=0.7\textwidth]{images/TheoryDesign/barmodes.png}
\caption{Left: List of applicable effects and filters. Right: Example of the workspace for an effect.}
\label{fig:barmodes}
\end{figure}

\subsubsection{Visualization Area and Middle-Bar}
The visualization area is divided into an upper and a lower window. These windows each visualize either the input or output signal in a time domain or frequency domain, depending on the user's preferences. The two windows are separated by a bar in the middle. Here the user is able to make certain changes to the visualizers and the input signal, see figure \ref{fig:visualizer}. From left to right the bar has the following options:

\begin{itemize}
	\item Two drop-down menus that allow the user to select what is to be displayed in the corresponding visualization window.
	\item Drop-down menu that allows the user to change the input signal, i.e. an oscillator or a repeating sound file.
	\item Effects button which toggles what is audible to the user, choosing between the unmodified signal and the modified signal.
	\item Reset button which resets the signal completely by removing all effects.
	\item Play/Pause button which allows pausing the signal, so the user can study parts of a sound more closely.
\end{itemize}

\begin{figure}[htbp]
\centering
\includegraphics[width=0.7\textwidth]{images/TheoryDesign/visualizer.png}
\caption{The visualizer windows and the middle-bar.}
\label{fig:visualizer}
\end{figure}

For each window, the user is able to freely determine whether the window shows the modified or unmodified signal and how it visualizes it, be it in a time domain or a frequency domain (\textbf{R1a}). It is possible to click on each of the two windows to maximize it to fill the whole screen. This could be used by teachers during lectures when showing off what different effects do to an input, for example when using a microphone (\textbf{R2b}).

Users are able to work with various input signals. The users can choose a sinusoidal wave oscillator or a sawtooth wave oscillator to generate an audio input. For this, the user gets a slider to change the frequency of the input. Alternatively, the user can import a sound file or use a microphone.

The placement of the options on the middle-bar has been determined by predicting a typical use case. The most used options, Play and Effects, have been placed furthest to the right, and the drop-down menus for changing the windows and changing the frequency of the signal, have been placed furthest to the sides. The reset button, the slider, and the play button, have intentionally been placed far apart from each other, as to not click any of them by accident (\textbf{R3d}).

The decision to make drop-down menus for the windows and the input signal worked against requirement (\textbf{R3c}). Instead, as with the Active Effects list, small icons could have been used. However, it was determined that requirement (\textbf{R1a}) was more important and therefore as much space as possible should be allocated to visualizing the sound. Because of this, the middle-bar has been made as slim as possible, but only to a point where it would still be usable on a tablet (\textbf{R2d}).

The middle-bar with all these general options has been placed in the middle for two primary reasons. The first is the fact that the bar contains options that are relevant for both the upper and lower window, and therefore placing it either in the top or the bottom of the window would seem confusing, as it would then be associated with only one of the windows and not both of them. The second reason is more aesthetically. Placing the bar in the middle has the purpose of, other than associating it with both windows, separating the two windows, so that there is a clear line between the two. This could be obtained by a simple thin line, but as the bar shouldn't be placed in the top or bottom of the program, it only seems natural to place it in the middle.

\subsection{Learning-Flow of the Program}
The layout of the program should be designed to naturally guide the user through the features without the need for tutorials or help-boxes everywhere. The layout has to present the features in a way that lets the user go through them at his own pace, while at the same time providing easy access to the next step. This is ultimately easier with a simpler program such as this, than it is with a more complicated sound editorial tool, because there are fewer features which need to be presented. This also allows for the removal of the regular top tool-bar, which is often seen in many desktop programs. 

For a user who does not have much, if any, knowledge regarding sound, it is important that the program has some features that he instantly understands and can relate to (\textbf{R2a}). The middle-bar is there to fulfil this exact purpose, having all the standard controls, e.g. pause/play, which are rather easy to understand, and which functions can clearly be seen when applied.

When looking at the interface of the program, which can be seen in figure \ref{fig:finaldesign}, it is expected that a completely new user will choose to start off with pressing play, as this is a button everyone knows what does. When the sound is playing, the user can change the sound by adjusting the oscillators frequency using the slider, and maybe change to another audio source. When the sounds have been changed, it seems realistic to expect that the user might do one of two things: either the user continues to go to the left and try out features, in which case he will try and see what the leftmost arrows are for, or the user chooses to see what reset actually does. Having gone through the middle-bar, it is assumed that the user now feels like he has a good idea of how it works and dares to move to the side-bar. Here it is expected that the user will press the drop-down menu as nothing else is present. 

The drop-down menu will present the user with a lot of options. The way the program works ensures that from this point on the user is more or less guided into the process of modifying the input and selecting the values of the parameters. When a change happens in the Active Effects list (when adding an effect), the user will also notice this and figure out its purpose. Having added an effect, the user now understands how the program works and will be ready to efficiently work with it and learn from the experience.

With the final design done, it is time to move on to implementing the program, following the chosen guidelines.